The Institute of Electrical and Electronic Engineers (IEEE) has promulgated a number of versions of a high speed serial bus protocol falling under the IEEE 1394 standard (referred to herein collectively as “1394”). A typical serial bus having a 1394 architecture interconnects multiple node devices via point-to-point links, such as cables, each connecting a single node on the serial bus to another node on the serial bus. Data packets are propagated throughout the serial bus using a number of point-to-point transactions, such that a node that receives a packet from another node via a first point-to-point link retransmits the received packet via other point-to-point links. A tree network configuration and associated packet handling protocol ensures that each node receives every packet once. The 1394-compliant serial bus may be used as an alternate bus for the parallel backplane of a computer system, as a low cost peripheral bus, or as a bus bridge between architecturally compatible buses.
The 1394 standard specifies two primary types of bus access: asynchronous access and isochronous access. Asynchronous access may be described as either “fair” or “priority.” Priority access is used by nodes that need the next available asynchronous opportunity to transfer data. Isochronous access is used by nodes that require guaranteed bandwidth with bounded latency, for example, nodes transmitting video or audio data. The transactions for each type of bus access are comprised of at least one subaction, wherein a subaction is a complete one-way transfer operation.
In the case of digital video data transfers within 1394-compliant systems, the video data may be transferred between a mass storage device and a digital video camera or other recorder under the control of a computer processor or other device. The video data is transferred as a series of frames, each frame being made up of a number of data packets. The individual data packets include a number header fields as well as the video data itself. In order to ensure that each frame of the video data is played out in the proper sequence, the frames are time stamped with an appropriate frame presentation time measured in terms of cycle time of an isochronous transaction on a 1394-compliant bus when they are recorded. The cycle time is maintained by a cyclemaster as described in the 1394 standard. The cyclemaster uses priority access to broadcast a cycle start packet. This initiates an isochronous cycle, during which nodes can use isochronous access, and contains the cyclemaster's cycle time clock information so that all nodes associated maintain the necessary synchronization for audio and video data.
Bus bridges between multiple buses of devices forward request and response subactions from one bus to another, allowing transaction requester and responder components to be located on different buses. Each bus has its own cyclemaster. An exemplary 1394-compliant network of three buses of devices is illustrated in FIG. 1. The first bus includes devices a1, a2, and a3 coupled together by 1394-compliant cables. Specifically, device a1 is coupled to device a2 by cable 40. Device a2 is coupled to device a3 by cable 42. Device a3 is then coupled to portal 22 of bridge 20. Bridge 20 couples the first bus to a second bus, which includes the devices b1, b2 and b3. Portal 24 of bridge 20 is coupled to device b1 by cable 46. Device b1 is coupled to device b2 by cable 48. Device b1 is coupled to device b2 by cable 48. Device b2 is coupled to device b3 by cable 50. Device b3 is coupled to portal 32 of bridge 30. Bridge 30 couples the second bus to a third bus that includes the devices c1 and c2. A second portal 34 of bridge 30 is coupled to device c1 by cable 54. Device c1 is coupled to device c2 by cable 56. Bridges 20 and 30 allow devices on the different buses to communicate with each other using both asynchronous and isochronous communications. For example, if device a1 sends a communication to device b3, the communication is passed along the first bus until it reaches portal 22 of bridge 20. Bridge 20 then recognizes that the communication is addressed to the device b3 and forwards the communication from portal 22 to portal 24.
The 1394 standard requires that 1394 bridges implement a method by which all the cyclemasters in a network are kept in phase. The topology used to model the method is shown in FIG. 2. One cycle master is elected to be the master or net cyclemaster. Cyclemasters on buses directly attached to the bus with the net cycle master are kept in phase with the net cycle master. In turn, other buses attached to these buses are kept in phase with the cycle masters on these buses, and so on. Each bridge is responsible for calculating the amount by which the cyclemaster on the bus on its alpha portal (the portal away from the net cyclemaster) is out of phase with the cyclemaster on the bus on its other portal, and accordingly issuing cyclemaster adjustment commands to the cyclemaster on its alpha portal to shorten or lengthen the cycle by one cycle_offset unit (40 ns). According to the method of the 1394 standard, the phase difference is sampled once during each isochronous period. The bridge simultaneously samples the value of CYCLE_TIME.cycle_offset for both of its portals and subtracts, modulus 3072, the upstream portal's cycle offset from the alpha portal's cycle offset.
FIG. 3 illustrates how the delay from the cyclemasters to the respective portals is considered by the 1394 standard method. The two cycle timers connected to the bridge provide, when simultaneously sampled, CYCLE_TIME.cycle_offset values denoted as upstreamOffset and alphaOffset respectively. In the example illustrated in FIG. 3, the upstream delay is 42 units, and the alpha delay is 17 units (as per the example in section 4.4 of the IEEE Serial Bus Protocol 1394.1). When the two cycle timers are simultaneously sampled, the correction to be applied to the alpha cyclemaster is (208+17)−(193+42)=−10. This negative value is interpreted as a “go faster” command, which causes the alpha cyclemaster to wrap at 3070 instead of 3071. The expectation is that on the next isochronous cycle, the difference will then be −9, and the method eventually brings the difference to a zero value.
However, in a distributed bridge, where the two portals are connected by a long haul or wireless medium, there may be no common clock to be sampled by the cycle timers simultaneously, so the method taught by the 1394 standard is useless. It is now desirable to attach devices by wireless connections to 1394 buses, as well as by significantly longer cable lengths. Thus, there is a heartfelt need to provide synchronization of cyclemasters that facilitate connecting wireless or longhaul connections.